Pinned pip depenency #284
Pinned pip depenency #284
Conversation
❌ 1 blocking issue (1 total)
@qltysh one-click actions:
|
soumeh01
left a comment
soumeh01
left a comment
There was a problem hiding this comment.
There are a few observations:
- We can't rely solely on the top-level mkdocs hashes, as pip requires hashes for all dependencies. Without including hashes for transitive dependencies, pip raises errors and refuses to install the incomplete requirements.
- The PR should resolve the linked issue. However, the auto update of the pip dependencies can only be tested when Dependabot creates a new update for the pip dependency. Until then, the expected behavior is that the changes should not alter existing functionality.
| repository: ${{ github.event.pull_request.head.repo.full_name }} | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
|
|
||
| # - name: Set up Python |
| pull_request: | ||
| paths: | ||
| - '.github/workflows/mkdocs.yml' | ||
| - '.github/requirements.in' |
There was a problem hiding this comment.
Should this be the .in file or the requirements.txt file with the hashes.
| @@ -0,0 +1,50 @@ | |||
| name: Recompile requirements.txt on Dependabot PRs | |||
There was a problem hiding this comment.
Do we have control over running the actions? I.e. to make sure that the mkdocs workflow only runs after the pip-update workflow? Apparently, there is an optional but strong dependency between the two.
| name: Recompile requirements.txt on Dependabot PRs | ||
|
|
||
| on: | ||
| pull_request_target: |
There was a problem hiding this comment.
👍 so this workflow's automated commits only happen on a branch, never on main?
| @@ -0,0 +1,215 @@ | |||
| # | |||
There was a problem hiding this comment.
Is requirements.txt the standard name of such lock files for pip?
There was a problem hiding this comment.
Yes, this is the standard name for Python pip packages.
soumeh01
added
the
do not merge
|
@soumeh01 , just to confirm that the idea of #283 is indeed to move documentation to a single MD file readable through extension registries like VS Code marketplace and in-tool MD readers showing during extension management. Anyway, thanks a lot for the investigation. It's good to understand what we can do in this area for PIP dependencies. I would suggest to wait with closing the PR until the other PR gets merged. Let's also make sure to keep the approach somewhere as an example for future pinning of PIP dependencies. I got a feeling we'll need this again sooner than we think... |
|
Closing this PR as the changes are redundant as mkdocs are no longer used. |
Fixes